So-called over the top services (OTT) in cellular wireless networks are services which a cellular operator may offer to the subscriber or user that may be offered by a third party. Such services could typically concern internet content such as video and audio for instance as internet television, IPTV and music—as well as text and pictures.
Operators have a large interest in being service aware; that is; to be able to differentiate services delivered for various applications, apps, or OTT services. This special service delivery may be a better quality of service, differentiated charging, etc.
In order to perform differentiated Service Delivery, it is key to identify the traffic that belongs to the Service. There are different known ways to identify such traffic as discussed in the following under items 1-4:                1. Use a specific Access Point Name, APN, per application. There a several issues with this approach:                    a. The terminal must be configured to use a different APN per application.            b. It is not feasible if the different Quality of Service, QoS, /Charging should be applied per subscriber            c. It requires multiple PDN connections and, therefore, multiple IPs.                        2. Use a 3GPP Rx interface from Application Server to an Operator Policy and Charging Rules Function, PCRF. The main drawback is that this solution implies that all application servers, and there might hundreds for a single application, should be connected with all the PCRFs of all Operators they have an agreement with. This is extremely costly to deploy and there currently is no real example of such deployment even if the technology has been available for a number of years        3. Solutions based on Deep Packet Inspection, DPI. In many cases the traffic needs to be identified through heuristic methods as the protocol is not public. DPI may, depending on the application, not be sufficiently accurate and therefore not suitable if there is a commercial agreement.        4. Solutions for Software Defined Networks, SDNs, require identifying traffic that belongs to a specific service. This is usually done through deep packet inspection, DPI, to identify the set of 5 tuples corresponding to the IP flows that a specific terminal has opened for the service in question. The set of 5-tuples are sent to a central entity, which uses that information to create a chain that is provisioned in all the open flow switches that belong to that chain. This result in a somehow excessive signalling traffic communication between entities and the solution may not be scalable.        